NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/4442

Text File | 1996-08-05 | 3.8 KB | 80 lines

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.c
Subject: Re: void main() and other atrocities!
Date: 4 Feb 1996 09:44:49 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <4eduaj$[e-mail]> <4epplj$[e-mail]> <[e-mail]> <[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <[e-mail]>,
Dan Pop  <[e-mail]> wrote:
>[e-mail] (Kazimir Kylheku) writes:
>
>>There is nothing with 'void main()'. It's not giverned by the ANSI standard,
>>first of all, because that is not an ANSI definition. An ANSI definiton would
>>be more like 'void main(void)'.
>
>'void foo()' and 'void foo(void)' are 100% equivalent as function
>_definitions_ in ANSI C.  They're different only when used as function
>_declarations_ (one is a prototype, the other isn't).
>
>>You don't need main() to be defined has having any sort of return value unless
>>you plan to "return" out of it. If you use exit(0) like me, declaring the
>>function void is ok, since your function never returns.
>
>BULLSHIT.  Please read the FAQ before posting such nonsense.
>
>    AxCrnA$ cc test.c
>
>    void main() {exit(0);}
>    .....^
>    %CC-E-NEEDNONVOID, In this statement, "main(...)" has void type, but occurs
>    in a context that requires a non-void result.
>    at line number 2 in file DISK$L32:[DANPOP]TEST.C;3

I know that it would break a compiler that generates an incompatible linkage
for functions returning int and void functions (assuming that the function you
are calling does not return). But I just don't know of any that do (and it
would be silly to write one that generates subroutine linkage code which breaks
when a void function is called that is assumed to be int).

It's also atrocious that main() has to be treated as a special language
construct, and that a call to exit() in main() (when it is the last statement)
is to be identical to a return.

I don't advocate that people declare main() to return void (in fact I don't do
so myself), but I don't see it as some sort of big mistake. In my own coding, I
sometimes even define the argv/argc parameters even if I don't use them, just
to meet the implicity prototype.

I did read the relevant section in the FAQ. It is merely concerned with the
issue of eliminating compiler warnings stemming from calling exit() in main()
despite a "void" declaration thereof. The issue that a void function may
not be compatible with a call to an int function doesn't seem that significant,
since nobody in their right mind would design a compiler that way.

In any case, I program using ANSI C only about 30% of the time. The
old-fashioned function declarations are more elegant. The only truly useful
thing introduced in ANSI C is the standardization of variable-length arg list
handling.  It's the only thing I really miss when working with non-ANSI
compilers. The other things I can handle myself: for instance, I don't need the
compiler promoting arguments to their prototyped types for me. An explicit cast
is more conscientious.

There is something magical about the old-style C that attracts me. I can't
quite put my finger on it. I was once a very good, careful coder. I wrote neat
programs in Modula 2 and similar langauges, always had carefully designed
abastract data types. All my cardinal variables belonged to carefully declared
and typed domains, arrays had typed ranges, etc.  It all went down hill from
there!

Now I'm increasingly catching myself writing assembly code, as though I had
gone full-circle. The arguments of what a main() function ought to be sound
like the buzzing of flies to me.

Can someone else identify with me? :)
--